Some points we missed in our latest planning.

Conflict with default method

If we enable "Restrict options" setting, but set the default cancel method to something that deletes, then:

• Users with option to choose a cancel method can only choose the remaining methods.
• Users without that option, but permission to cancel their own account, can permanently delete their own account.

Interesting find in AccountSettingsForm:

    $form['registration_cancellation']['user_cancel_method'] += user_cancel_methods();
    foreach (Element::children($form['registration_cancellation']['user_cancel_method']) as $key) {
      // All account cancellation methods that specify #access cannot be
      // configured as default method.
      // @see hook_user_cancel_methods_alter()
      if (isset($form['registration_cancellation']['user_cancel_method'][$key]['#access'])) {
        $form['registration_cancellation']['user_cancel_method'][$key]['#access'] = FALSE;
      }
    }

See the comment about 'access' key.
This means that fixing the @todo about 'access' would actually fix one half of this dilemma.

Right now / with this PR, the available options in the account settings form are dependent on your user account, that is, whether you are uid 1.

I think this entire problem is not a regression, so we could move ahead and ignore it for now.

Which form to use

From UX perspective it seems this setting belongs into "Account settings" form, not "Authentication settings".
Only from the module developer perspective it would make sense to put it in "Authentication settings" because the functionality is provided by oe_authentication module.

TBD with rest of the team.

As per #79 (comment), it's for the site developers to configure a proper default method when restricting the options. Since the module behaves already in that way, we won't add anything as part of this pull request. We could iterate in a different one.